EDI

Here, there are two ways in which the configuration can take place. We can distinguish between self-managed in-house, and in-house with service provision.

SaaS is also known as cloud computing. Here, the installation itself is outsourced. That means a provider makes hardware and infrastructure available, and takes care of maintenance matters such as the installation of updates. You can then control everything and set up your own processes via the Internet.

In principle, it is possible to outsource not only the system operation and administration, but all the work too. A service provider runs the software in their own data centre, connects your business partners to it, and sets up conversions and other processes. All you have to do is send the data for your partners to the provider’s system, and the provider then sends your partners’ data back to you.

Communication also forms part of EDI – and here we have two alternatives. You can send data either via the standard Internet, or via a VAN (value-added network). The latter comes with a few additional features beyond pure data transfer, such as secure transfers. Let’s take a closer look at the alternatives:

Pros:

• All your systems – such as databases, SAP, and everything else besides – are directly accessible, allowing the EDI system to make use of its full capacity.
• If the program is able to, it can also carry out EAI tasks at the same time, since the previous point is of course an essential prerequisite to this.
• Everything is fully under your control – nothing leaves your network beyond the data that were intended for the outside world anyway.
• You only need to make a single investment when buying the system, followed at most by a manageable and unchanging support fee. That fee won’t go up even if your data volumes increase exponentially.

Cons:

• • You need to supply your own hardware and infrastructure, and of course there are certain administrative costs involved too – although those costs will depend on which additional service you decide to purchase.
  • The initial investment is somewhat more substantial.

  Deciding where to install the software is only half the challenge, however. You also need to think about who will then work with the system and implement your processes. We can split that decision into two general alternatives (although the boundaries between them are somewhat fluid, of course).

This gives you full control over everything. The installation will probably still be carried out by the manufacturer or a service provider, but the day-to-day work will be done by your employees. That means your IT unit (and most larger companies generally have a dedicated EDI team too) will configure the communication with your partners, establish all the processes, conversions, workflows and so on, and of course connect your internal systems too. The manufacturer’s support team would naturally stand ready to assist you with this, but it would largely be up to you.

That sounds like a lot of work – and it is – but it’s also worthwhile, since everything you do yourself will also be fully understandable to you afterwards. If any changes need to be made, this can be done quickly without having to provide complex explanations of what you need to a service provider, and without having to wait until the provider has time for your project.

Of course, changes to processes (such as switching to a newer version of an EDIFACT message) generally involve a certain lead time, which means this might not be so important. But what if your supplier calls on Friday afternoon and tells you that the IP and name of their FTP server to which you send all of your orders will be changing in two hours? Someone from your IT unit will need to be able to stay on-site to make the changes, since a service provider might close early on Friday or be so busy that they can only get round to it halfway through the following week.

You can also manage extensions to your software in-house, insofar as this is technically possible. And provided you have the right people for the job, of course. But a word of caution here: Even if the manufacturer provides you with the interfaces (or APIs), they will absolve themselves of responsibility for any lines of code that you have written or introduced into the system yourself. On the other hand, that would still be true if you had written everything for yourself without using any standard software.

In any case, this scenario calls for comprehensive training for your employees. That should start with administration, data backup and logging, but it should also include day-to-day operation, set-up of processes and communication, as well as using the API for in-house extensions (if this is available and relevant to you). Yet because training can generally only cover the fundamentals and just a small proportion of the countless functions found in a complex system of this kind – and because your employees will only retain a small part of the training anyway – quick, reliable and helpful support from the manufacturer is absolutely essential in cases like this. You should therefore research the company in advance and look carefully at its reputation for support. There should also be comprehensive documentation available, as it’s generally quicker to look at the manual than to send an email to the support team.

And make sure you don’t reinvent the wheel in the process. Connections to standard communication paths (from AS2 to X.400) and the use of standard data formats (EDIFACT, Fortras, VDA, etc.) should be supported by the system through simple templates and preset structure definitions.

Pros of this solution (in addition to the general ‘in-house’ component):

• You know exactly what is going on in your system as you’ve set it all up yourself.
• That means you can make changes quickly.
• You can respond instantly to errors and problems.
• Updates can be installed over the weekend when the system can be put out of action temporarily (and a service provider would only be available for a higher fee than usual).
• Your internal data will never fall into the hands of third parties. This is particularly important in the healthcare sector with its strictly confidential patient data, as well as among banks and insurance companies.
• If extensions are permitted by the system, they can be implemented quickly.
• Your employees know how everything works. You understand the processes in your business, which means you don’t need to provide lengthy explanations to a service provider.

Cons:

• Your employees will need comprehensive training in order to be able to operate and administer the system properly. It will also take them a while to gain enough experience to properly get to grips with it.
• That means you’re dependent on quick and effective support.
• Your need human resources to administer and operate the system.

• Was kann man denn so alles von einem Dienstleister machen lassen?
  • Administration mit Einspielen von Updates und Bugfixes
  • Einrichten der Kommunikation mit den Partnern
  • Anbinden der anderen Systeme (ERP, DB, …) im Haus
  • Aufsetzen von Konvertierungen zwischen Datenformaten
  • Abbilden der gesamten EDI-Prozesse
  • Monitoring des laufenden Betriebs und Reaktion auf Fehler

  Wie viel Dienstleistung Sie  in Anspruch nehmen und was Sie doch lieber selbst in der Hand behalten, können Sie natürlich im Einzelnen entscheiden. Hier schildern wir mal das Extrem, dass alles ausgelagert wird. Wobei das spätestens beim Monitoring an eine kritische Grenze stößt, denn zumindest das sollte bei einem Inhouse-System in Ihrer Hand bleiben. Auch für einen Dienstleister dürfte es schwierig werden, X Kundensysteme ständig zu überwachen, die womöglich über die halbe Welt verstreut sind.

  Was Sie sich hier ganz klar sparen können, ist eine ausführliche Schulung. Sie sollten zwar trotz Allem über die grundsätzliche Funktionsweise Ihres Systems Bescheid wissen, da man seine geschäftskritischen Daten wohl nur ungern einer Black Box anvertraut, aber detailliertes Wissen über Konfiguration, Administration und Abbildung der Prozesse ist in diesem Fall nicht nötig. Wenn Sie etwas brauchen, einen neuen Partner anbinden wollen, mit einem neuen Datenformat konfrontiert werden oder ähnliches, dann beauftragen Sie den Dienstleister damit. Der hat Spezialisten, die den ganzen Tag nichts anders machen und sich in allen Ecken der Software bestens auskennen.

  Womit er sich allerdings nicht auskennt, ist exakt Ihr Betrieb. EDI ist kein Feld für 08/15-Lösungen, selbst zwei oberflächlich betrachtet identische Prozesse können bei verschiedenen Unternehmen vollkommen unterschiedlich aussehen. Als Beispiel nehmen wir eine simple Datenkonvertierung von Lieferabruf-Daten aus dem Format VDA 4905 in ein EDIfact DELFOR. Schon das VDA-Datenformat bietet so einige Freiheitsgrade, da nicht alle im Format möglichen Angaben auch tatsächlich verpflichtend gemacht werden müssen. Das EDIfact-Format ist da noch „einen Tick“ umfangreicher. Im Bild unten sehen Sie nur einen Teil dieser Struktur:

  Struktur des Formats VDA4905 in Lobster_data	Struktur des EDIfact DELFOR (Version D 12 B) in Lobster_data

   

  Sie sehen rechts zum Beispiel in der Segmentgruppe 2 (SG2) ein NAD-Segment, NAD steht für „Name and address“. Ein weiteres solches Segment sehen Sie in der SG7, die unterhalb der SG6 liegt, in der es um Vorgehensanweisungen (Processing instructions) geht. Und was man hier nicht sieht: Noch weiter in den Tiefen der Struktur kommt das NAD noch einmal vor, auf Ebene der einzelnen Positionen. Es gibt also nicht die Umsetzung schlechthin von VDA4905 in DELFOR, sondern eine ganze Palette von Möglichkeiten.

  Genau hier haben Sie dem Dienstleister gegenüber einen gewaltigen Wissensvorsprung: Sie wissen, welches der vielen, im DELFOR vorkommenden, NAD-Segmente in diesem speziellen Fall genutzt werden soll. Oder Sie können diese Information zumindest direkt bei Ihrem Partner, für den die Daten bestimmt sind, erfragen. Hinzu kommt: Im VDA-Format gibt es gerade ein mal die Kundennummern von Lieferant und Kunde, detaillierte Adressinformationen kommen hier gar nicht vor. Sie wissen aber dann, ob es reicht, einfach ebenfalls Kunden- und Lieferantennummer einzutragen, wie sie im VDA stehen, ob man sie von einem Nummernkreis auf einen anderen (ILN) umsetzen muss oder ob auch die gesamten Adressangaben benötigt werden. Und noch viel wichtiger: Sie wissen, aus welchem Ihrer Systeme Sie diese Informationen bekommen können und auf welchem Wege.

  Das alles können Sie natürlich dem Dienstleister, der für Sie die Konvertierung aufsetzt, mitteilen. Es verursacht aber zusätzlichen Kommunikationsaufwand, der erfahrungsgemäß in ein ausgiebiges Frage-Antwort-Spiel ausartet. Bei komplexen Prozessen, die die Gegebenheiten in Ihrem Unternehmen berücksichtigen müssen, wird das Ganze noch viel spaßiger.

  Was Administration, Anbindung von Systemen und Kommunikation angeht, sieht es ähnlich zweigeteilt aus. Einerseits hat natürlich der Hersteller der Software oder ein spezialisierter Dienstleister die größte Erfahrung nicht nur mit seinem System, sondern auch bezüglich des Zusammenspiels bestimmter Fremdsystemen (z.B. Datenbanken). Andererseits sind doch wieder Sie es, die erst die nötigen Informationen zusammenstellen und ihm weiterreichen müssen, damit er das Ganze dann umsetzt. Mal salopp gesagt: Bis dahin haben Sie’s auch schon selbst erledigt.

  Vorteile:

  • Sie müssen nicht im eigenen Hause tiefergehendes Wissen über die Funktionsweise des Systems aufbauen.
  • Konvertierungen und andere Prozesse profitieren von der Erfahrung des Dienstleisters im Umgang mit der Software.
  • Sie sparen sich personellen Aufwand.

  Nachteile:

  • Hoher Kommunikationsaufwand für jede neue Anbindung, jeden neuen Prozess und jede Änderung
  • Sie müssen immer noch einen Teil der Arbeit machen, um den Dienstleister mit den nötigen Informationen zu versorgen.
  • Der Dienstleister kann nicht immer sofort reagieren, Sie sind auf seine Resourcen angewiesen.
  • Evtl. müssen Sie dem Dienstleister Informationen geben, die Sie eigentlich lieber im Hause behalten möchten.

  Zusammenfassung
  Wenn das System schon bei Ihnen im Hause steht, sollten Sie es nutzen, indem Sie volle Kontrolle über alles behalten. Sicher können Sie einige Arbeiten an einen Dienstleister auslagern, was den anfänglichen Schulungsaufwand reduziert und schneller zu guten Ergebnissen führen kann. Erwarten Sie aber nicht, dem Dienstleister nur ein paar Stichworte zu geben und dann entspannt auf das Ergebnis warten können. Sie können Arbeitszeit ihrer Mitarbeiter einsparen, aber ganz ohne geht es nicht.

The EDI system is installed somewhere in a data centre – theoretically on the other side of the world. The data centre operator ensures that the system is highly available, takes care of data backups, installs updates and bug fixes, and – of course – provides the entire communications infrastructure. You make use of all this from your business premises via

the Internet, a browser or a special client. You can set up communications channels from the data centre to both your partners and yourself, since the data need to be able to travel back and forth between your systems and the EDI system in the data centre. You can also map out data conversions and process chains exactly as you need to – this is fully under your control. And of course, you can keep an eye on whether everything is running smoothly. So far, so good. It means you save money on hardware and infrastructure, and the entire system administration is also left up to the operator.

And because the system isn’t installed on your premises, you just pay for usage rather than for an entire system up-front. There are various tariff models available, so you can be charged per active interface, by the number of messages/conversions, by volume of data, and much more besides. This naturally saves you having to make substantial initial investments.

Yet the concept quickly reaches its limits once your requirements go beyond simple format conversions and communication. For instance, things get complicated when you also need to enrich data – e.g. by obtaining name and address data to go with a customer number. This is because data of this kind are stored in databases and in other systems on your own network, and not in the data centre. Of course, you can build a VPN link to allow the data centre to access your network, but that will have a big impact on performance – not to mention the accompanying security issues. It’s also an additional point of weakness, since while the data centre might be able to guarantee high availability, the VPN link can quickly collapse under the weight of DSL problems (for example).

If all you have are simply designed EDI processes – just data transport and conversion – then SaaS can be a very good option. It may also be possible to tack on simple enrichment and implementation tasks (e.g. country codes) relating to small files. Yet if a closer connection to the rest of your IT landscape is needed, SaaS will quickly get you into difficulties. If you need a single system that can also carry out EAI or ETL tasks, then you will have to turn to an in-house solution.

Pros:

• No need for either hardware or infrastructure (aside from an Internet connection).
• A data centre can guarantee you a whole other level of availability.
• You don’t need to worry about purely administrative tasks, such as updates.
• There are no major initial investments involved.

Cons:

• You are dependent on the reliability of the operator.
• The rest of your IT landscape is inaccessible, or accessible only by making special arrangements.
• This means there is no chance of using the same system to also handle EAI or ETL matters.
• Business-critical data and processes are stored with a third-party.
• The running costs can quickly mount up to become more expensive than an in-house solution would have been, depending on the intensity of use and the tariff model.

If you are currently only looking into EDI because your business partners have asked you to, and you don’t have more than a handful of simple connections to make, then SaaS can look very enticing. However, if you can foresee that this whole area will grow for you over the next few years (and there is a very good chance that it will), then you should look for a provider who will let you adopt both options. You could start with SaaS (or even EDIaaS), and then simply move the interfaces to your own premises when the time comes for an in-house installation. If you are using the same software then a transfer of this kind shouldn’t prove too difficult.

Pros:

• No in-house hardware or infrastructure required – instead, you get the reliability of a data centre.
• Service providers generally offer a wide range of possible communication paths.
• The service provider has a lot of experience in dealing with software and data formats, as they work with these on a daily basis.
• There are no major initial investments involved.
• Relatively little work required on your part.

Cons:

• No control whatsoever over business-critical data and processes.
• Complete dependence on the service provider (trustworthiness, human resources, etc.).
• The rest of your IT landscape is inaccessible, or accessible only by making special arrangements.
• That means there is no chance of using the same system to handle EAI or ETL matters.
• Depending on the usage intensity and the tariff model, the running costs can quickly mount up to be more expensive than if you were using an in-house solution.

Even more so than SaaS, EDIaaS is suitable only for a handful of very simple EDI scenarios. When things get significantly more complex, this solution becomes ineffective. And it also leaves you with less control over your own data and business-critical processes than was the case with SaaS. The same advice applies here: If you want to use this method as a starting point for EDI, you should choose your provider intelligently so as to give yourself the option of switching to a more flexible alternative at a later date without having to completely reconfigure everything.

This might sound fantastic at first, but it’s only an ideal scenario. For it to happen in practice, every single communication partner needs to be connected to the same VAN, which is rather an unlikely proposition. Of course, it’s possible that the VAN might offer you communication with “the outside world” – but then you’re back on the normal Internet, where advantage 2 no longer applies. Configuring the various communication channels shouldn’t prove too difficult with decent EDI software, since we’ve come a long way in that regard over the last few years.

Leaving aside the fact that there is no such thing as an unhackable network, a huge range of widely available standards have now been developed especially for secure transfers. Whether HTTPS, FTPS, SFTP/SCP or AS2, encryption is used everywhere. With AS2, there are many different ways for you to work with encryption and data signatures, and receipt confirmations are mandatory here too. So if you use modern transfer methods, you’ll find that this benefit has long since been matched online.

In other words, the advantages that VANs used to enjoy have been largely caught up on during the evolution of the Internet. The disadvantage remains unchanged, however: it costs more money. Whether you’re charged a monthly or annual fee or an additional fee for each file you send or receive, you will be paying extra for a service that you could just

as well obtain via another method.

As mentioned above, we are discussing a situation where the extra work involved in EDI (e.g. conversion, reconciliation, enrichment, and so on) is already covered by a specialist system. If all you need is simple EDIaaS, the offer of a suitable VAN may be sufficient for your needs (although in this day and age, it is barely imaginable that anyone would willingly restrict themselves solely to communication partners who are connected to the same system…).